[iOS] [Android] iOS エンジニアが Android をやることによって変わった6つのこと

[iOS] [Android] iOS エンジニアが Android をやることによって変わった6つのこと

Clock Icon2015.10.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、モバイルアプリサービス部の荒川です。

弊社のモバイルアプリサービス部は、以前まで「iPhoneアプリサービス事業部」という部名でした。その名の通り、iPhone のアプリ開発に力を入れて、アウトプットのおよそ8割は iPhone(iOS)に関するものでした。しかし、モバイルアプリ開発の受託では、「一緒に Android 版も作って欲しい。」という要望が多いです。そのため、部名にはない Android アプリも並行で開発することが多かったです。

私は、2015年の4月までは iOS の開発のみを担当していましたが、最近では Android の開発も並行して行っています。

この記事では、私が上記の経緯で得た知見や、気づいたこと・良かったことを紹介します。記事の内容の大半が私の振り返りなので、技術ブログというよりは、個人ブログに近くなっています。ご了承ください。

モバイルアプリのエンジニアに限らず、1つ以上の言語を学習したことがある方・これからやってみたい方を対象読者とします。

iOS エンジニアが Android をやることによって変わった事

iOS エンジニアだった私が Android の開発に携る事で、以下の事が大きく変わりました。

  • Android のソースコードレビューができるようになった
  • iOS・Android の設計を意識するようになった
  • プロジェクトの進捗状況によって、スポットで iOS・Android のサポートに入れるようになった
  • README や ChangLog(GitHub Release) に開発環境やビルド手順をしっかりと残すようになった
  • モバイル開発チームで会議をする時などに、コミュニケーションが円滑に行えるようになった
  • やれる仕事の幅が広がった

以下に各項目の詳細を書きます。

Android のソースコードレビューができるようになった

GitHub で Android の Pull Request を私がレビューできるようになりました。iOS とロジックが乖離している場合、即座に気づいて指摘する事ができます。UIについては、まだまだ私の知識が足りていないので、都度実装者と確認しながらレビューを行っています。

iOS・Android の設計を意識するようになった

プロジェクトの規模によって、モバイルアプリの設計は様々です。それでも、プロジェクト構成(iOS ではグループ、Android ではパッケージ)やロジックを出来るだけ、iOS と Android で合わせています。これによって、テストコードも似たような構造にできます。新規に処理を追加する場合も、iOS が先行していれば、 Android にすぐに書き起こせる(逆も然り)ようになりました。

プロジェクトの進捗状況によって、スポットで iOS・Android のサポートに入れるようになった

GitHub で Pull Request ベースの開発を行っていると、割り込みタスク等によって、レビューが滞ってしまう事があります。そういった時に、私がスポットでレビューを行えるようになりました。

さらに、iOS・Android どちらかの進捗が芳しくない場合は、一時的に注力して解決する手助けもできるようになりました。

README や ChangLog(GitHub Release) に開発環境やビルド手順をしっかりと残すようになった

README

iOS・Android の開発環境構築(Xcode, AndroidStudio, OSSの管理, 初期設定, ビルド設定)を手順にまとめる事を意識するようになりました。仕事で初めて Android 開発(引き継ぎ)に携わった時に、環境構築が手順化されていなくて、前の担当者に何度も聞くという経験がありました。今は私が引き継ぎをする場合に、そうならないようにしています。

長い目で見ると、こういった単純な事でも時間を割いた方が良いと思います。後任の担当者に聞かれた場合、私が詳細に覚えている自信もなく、失う時間がドキュメントを書く時間より多くなると思っています。

ChangeLog

GitHub の Issue 駆動で開発を進めている事を以前の記事、【開発者のタスク管理をGitHubで行ったらうまくいった話】 で紹介しましたが、今もこういった開発方法で進めることが多いです。こちらでも紹介した GitHub Release を ChangeLog 代わりに使っています。 Issue ベースで開発を進めている場合、コピペでリリースノートが出来上がります。

ChangeLogを残しておくことで、READMEと同様に後々失う時間を減らす事が出来ると思っています。

上記2つは自分のためでもあり、引き継がれた方のためにもなるので、チームの誰よりも積極的に書くように意識しています。

アプリ開発チームで会議をする時に、コミュニケーションが円滑に行えるようになった

プロジェクトのアプリ開発チーム(iOS、Android)の打ち合わせなどで、臨機応変に振る舞える事が以前よりも増えた気がします。例えば、iOS・Android だけの独自仕様が存在する場合なども、容易に理解できるようになりました。

CI 等で自動化をする場合も iOS・Android どちらも構築できるようになりました。

やれる仕事の幅が広がった

私自身は、1日のうちの半分をiOS・半分を Android といった働き方でも集中力が一定に保てる(逆に言えばものすごく集中している時間がないのかも・・・w)ので、やれる仕事の幅が広がって、素直に嬉しいです。「今日は iOS だけに集中したい!」という方もいると思うので、そういう時は事前にチームメンバーに申告しておくと良いとでしょう。

まとめ

iOS エンジニアが Android を学習することで、iOS に関する知識が以前より増したかと思います。特に設計やユニットテストについては強くそう思います。

iOS の良いところ・Android の良いところをそれぞれ知って、プログラミングの面白さ(ワクワクする感じ)を思い出せました。更に新しい技術に触れたいとも考えるようになりました。ただ、「中途半端な何でも屋」にはなりたくないので、しっかりと技術を習得してからを考えています。

サーバーサイド(Go・Elixir)・インフラ(AWS)・ゲーム(Unity・Cocos2d-x)も私の引き出しにしたい思っていますが、それはまた今度考えます。(しばらく言っている気がする・・・。)

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.